Reapply PR#31: optimize retry pool #5113
Conversation
|
Backports to the beta branch are to be avoided unless absolutely necessary for fixing bugs, security issues, and perf regressions. Changes intended for backport should be structured such that a minimum effective diff can be committed separately from any refactoring, plumbing, cleanup, etc that are not strictly necessary to achieve the goal. Any of the latter should go only into master and ride the normal stabilization schedule. Exceptions include CI/metrics changes, CLI improvements and documentation updates on a case by case basis. |
| @@ -298,9 +308,17 @@ impl SendTransactionService { | |||
| { | |||
| // take a lock of retry_transactions and move the batch to the retry set. | |||
| let mut retry_transactions = retry_transactions.lock().unwrap(); | |||
| let transactions_to_retry = transactions.len(); | |||
| let mut transactions_to_retry: usize = 0; | |||
There was a problem hiding this comment.
transactions_to_retry changed the semantics: now it is number of transactions that haven't reached retry limit.
| @@ -369,6 +388,17 @@ impl SendTransactionService { | |||
| stats, | |||
| ); | |||
| stats_report.report(); | |||
|
|
|||
| // to send transactions as soon as possible we adjust retry interval | |||
| retry_interval_ms = retry_interval_ms_default | |||
There was a problem hiding this comment.
it means just retry_interval_ms_default - (ms since last send) to prevent sleeping longer than retry_interval_ms_default (because between the moment when we sent and current moment some time passed).
Problem
Transactions not included in the retry pool on full utilization
This PRs adds back #31
Summary of Changes
TransactionInfo